@Gąska said in Re: Go stand behind him: @pie_flavor said in Re: Go stand behind him: @Gąska said in Re: Go stand behind him: @pie_flavor said in Re: Go stand behind him: @Gąska You're missing it. Serialization is done by reflection at runtime. That's bad. Not horrible, but bad (mostly because of performance). Mixins are done by reflection at runtime. That's horrible. Like, actually horrible, worse than not having mixins at all. What the fuck are you on about? What did you think happened in annotation based serialization / mixin systems? It's not done by gremlins. Maybe it's baked on first use and maybe the annotations are reinterpreted each time but there is absolutely no way to do an annotation based system without reflection. Yes there is? Just move the runtime stuff to compile time. Surely it's not hard to imagine. And from what I understood from your rambling about Lombok, it's certainly possible to do all that at compile time in Java. It even makes more sense to do it at compile time than at runtime, since you can type check all the code and make sure everything actually works before the relevant code path even gets run. Moving to runtime the stuff that defines what kinds of operations your class even supports is huge . Not the first time Java turns out to be huge . Again: what are you on about? Example. @Listener goes on a method, and the class that contains it gets registered with the EventManager. Said EventManager figures out that it should wrap the class in an EventListener, and when the listener's invoked, pass the event as the first method argument and various fields inside the event as the remaining arguments. How would you move this to compile-time if, for example, EventListener was not present in the API and the API was supposed to be implementation-agnostic? What I said is that code that compiles with APT processors should not fail to compile without APT processors. But why? There's literally no reason whatsoever to do that. It's like saying that programs using Stream APIs should not fail to compile without Stream APIs present. Annotations aren't APIs. Do they inform external code what kind of operations can be performed on your class? Then they're API. No matter how much you'll ramble about compile time vs. runtime, about APT processors and lack thereof, it all comes down to this one thing. Does the annotation enable your code to be used by external code? Then it's API. The annotation is not what enables your code to be used by external code. My method labeled @Listener can be called by anything. Any class that wants to can call MyPlugin.instance().onInit(new GameInitializationEvent()). The annotation is additional information that the event manager uses to determine that the method should be called when a GameInitializationEvent is posted. If @Listener was knocked off, it would not affect external code's ability to use the method - it would just be a change in metadata. e: Oh yeah, and this ability to dynamically fuck with the AST at compile time is documented but unsupported. It's liable to break any time Oracle feels like it, and in fact Lombok isn't working on Java 9-11 yet.